Clearinghouse System for the Collection, Management and Identification of 340B Related Pharmaceutical Claims Under Various Medicaid and Medicaid Managed Care Programs

ABSTRACT

The present invention is directed to an exchange clearinghouse, to provide an improved method of processing all 340B Drug Pricing Program claims for all involved parties, to easily identify and report the 340B claims as well as overcome any challenges of the prior art without compromising security or accuracy. More particularly, the invention is a method that can alter, change, or reclassify previously adjudicated pharmacy claims (original claims) through a system, outside of and unrelated to the system used by the pharmacy service provider who adjudicated the original claim. This creates a reversing claim of the original claim and recreates an altered, changed or reclassified original claim. The Method also allows for the collection and reporting of accurate quantities of the original claim in which 340B priced drugs were used.

PRIORITY CLAIM TO RELATED APPLICATION

This application claims the benefit of previously-filed U.S. ProvisionalPatent Application, Ser. No. 61/994,456, filed on May 16, 2014, entitled“Clearinghouse System for Processing Pharmaceutical Funding Claims UnderVarious Medicaid Programs”, as well as previously-filed U.S. ProvisionalPatent Application, Ser. No. 62/018,206, filed on Jun. 27, 2014,entitled “Clearinghouse System for Processing Pharmaceutical FundingClaims Under Various Medicaid Programs.” The entireties of thosepreviously-filed applications are incorporated herein by this reference.

BACKGROUND

1. Field of the Invention

The present invention relates generally to computerized systems forconsolidated processing of Medicaid claims and, more particularly, toconsolidated 340B Medicaid processing systems that are accessible tovarious user types through internet portals, by which data is collected,validated and managed as part of a pharmaceutical rebate program.

2. Description of Related Art

The United States Congress has tried time and again to help ensureaffordable healthcare in the face of ever-increasing pharmaceuticalcosts, but the implications for healthcare providers are oftenconfounding. In 1990, Congress created the Medicaid Drug Rebate Programto help offset the rising costs. The program effectively created acontractual relationship between pharmaceutical manufacturers andgovernment agencies, particularly the Centers of Medicare and MedicaidServices (CMS) and state-run Medicaid Agencies, creating a rebateincentive aimed at helping offset the Federal and State expenses of mostoutpatient prescription drugs dispensed to Medicaid patients. Theprogram required participating pharmaceutical manufacturers to providerebates for certain medication purchases, in exchange for having theirproducts covered by Medicaid. Nice idea, but it unexpectedly causedoverall prices to drastically increase. Because the required rebate wasbased on each manufacturer's “best price”, the program nullified anyincentive for manufacturers to reduce their prices in non-Medicaidmarkets, as doing so would lead to larger rebates in the Medicaidmarket. As a result, non-Medicaid patients were often charged higherrates than otherwise would have been charged prior to the Medicaid DrugRebate Program.

Therefore, in 1992 the United States Federal Government created the 340BDrug Pricing Program, which required drug manufactures that currentlyparticipate in the 1990 Medicaid Drug Rebate program, to provideoutpatient drugs to eligible healthcare organizations, safety netproviders and covered entities at a significantly reduced price.Congress has stated that the primary goal of the 340B Drug PricingProgram was to allow covered entities to “stretch scarce federalrecourses as far as possible, reaching more eligible patients andproviding more comprehensive services.” The 340B discount is the samediscount that manufacturers are required to provide to State Medicaidagencies. The intent was to maintain a high level of medical serviceswhile reducing medication costs for certain patients. The 340B Programhas been amended and expanded multiple times since its enactment.

To participate in the 340B Program, eligible organizations such ascovered entities, or Health Centers, must enroll and comply with all340B Program requirements. Once enrolled, a covered entity is assigned a340B identification number. The covered entity must then informmanufacturers and distributors that they wish to participate in the 340BProgram when placing orders. Manufacturers and suppliers must verifythat the health center is enrolled in the 340B program in order to selloutpatient drugs at the 340B discounted price. Thus, under the 340BProgram, congress protects specific hospitals and clinics from drugprice increases as well as giving those specific hospitals and clinicsaccess to price reductions.

This program requires drug manufacturers to enter into and have ineffect, a rebate agreement with the Secretary of the Department ofHealth and Human Services in exchange for state Medicaid coverage onmost of the manufacturer's drugs. The manufacturers are responsible forpaying a rebate for the covered outpatient drugs each time they aredispensed to Medicaid patients. These rebates are paid by drugmanufacturers at predetermined intervals to the States and are sharedbetween the State and the Federal Government to offset the overall costof prescription drugs under the Medicaid program.

To date, there are approximately 600 different drug manufacturerscurrently participating in the 340B Drug Pricing Program. Further, allfifty states and the District of Columbia cover prescription drugs underthe Medicaid Drug Rebate Program.

Despite the long history and wide spread industry use of the 340B DrugPricing Program, the program still presents significant challenges forall parties involved. For example, while numerous medical providers relyon the program, it is difficult for those providers to effectivelysubmit, process and manage claims under the 340B program.

A similar problem with the current system is that a significant amountof time, labor and effort is required for every pharmaceutical drugmanufacturers or wholesalers to verify that each entity requesting thespecial 340B discounted rebate price has in fact been registered,approved, and enrolled in the 340B Drug Pricing Program.

Another problem with the current system is that each health center canhave its own negotiated price with a manufacturer for a certainpharmaceutical drug. The listed 340B pharmaceutical drug price is thehighest price that covered entity would have to pay a manufacturer forthe drug, as the price is based on the Average Manufactures Price, lessa discount that is equivalent to the states Medicaid drug programdiscounts. Health Centers can, negotiate prices with the manufacturersthat are below the 340B Program drug price, thereby creating additionaldifficulty in processing the 340B Rebates as there is no singular price.

Additionally, drug manufacturers provide a discount to health centersand other covered entities when they purchase a drug. Health centers andother covered entities can use the discounted 340B drugs for allpatients. However, since health centers must charge patients differentlyfor the drugs, dependent on whether each individual patient qualifies toreceive the drug at the discounted 340B price, thereby created an issuein verifying that drug manufacturers are repaid.

A similar problem with the current system is that health centers mustkeep track of which program is paying for the drugs in order to maintaincompliance with the 340B rules. Drug manufacturers that participate inthe Medicaid Drug Rebate Program must also participate in the 340Bprogram. The discount amount is the same in the Medicaid Drug RebateProgram and the 340B Discount Program. However, while drug manufacturersparticipate in both programs, only one discount can be used.Specifically, either the state Medicaid agency receives a rebate pricefor the drugs provided to a Medicaid patient or the health centerreceives the 340B discounted price for its Medicaid patients.

As a result, there are numerous shortcomings, to both the patient andthe provider, of the current system as utilized in the industry, whichcauses devastating financial implications, and therefore, as aconsequence patient care could be compromised.

Many other problems, obstacles, limitations and challenges will beevident to those skilled in the art, particularly in light of theliterature and experiences that are known in the industry. Therefore aneed exists for systems and methods for identifying, tracking, andhandling all aspects of the 340B discount program.

It would therefore be desirable to provide a system and method whichcould rapidly provide information for manufacturers, providers,patients, and government entities in order to consolidate the financialburden regarding the 340B prescription rebates as well as streamlinecommunications between covered entities and pharmaceutical drugmanufacturers or wholesalers. It is further desirable that healthcenters have a management information system that is able to handle andverify who should receive the 340B pricing and those who should not, aswell as have the ability to track pricing for their drug sales to ensurethe right prices are received.

SUMMARY OF THE INVENTION

The present invention is directed to an exchange clearinghouse, toprovide an improved method of processing all 340B Drug Pricing Programclaims for all involved parties, to easily identify and report the 340Bclaims as well as overcome any challenges of the prior art withoutcompromising security or accuracy.

The primary purpose of the present invention is to improve upon theprior art and enable better management of all aspects of processing andfulfilling 340B funded pharmaceutical supply chains. More particularly,the invention is a method that can alter, change, or reclassifypreviously adjudicated pharmacy claims (original claims) through asystem, outside of and unrelated to the system used by the pharmacyservice provider who adjudicated the original claim. This creates areversing claim of the original claim and recreates an altered, changedor reclassified original claim. The Method also allows for thecollection and reporting of accurate quantities of the original claim inwhich 340B priced drugs were used.

The Clearinghouse Method allows claims in which 340B drugs were used toreported accurately in ways in which the traditional National Council ofPrescription Drug Programs (NCPDP) 340B “prior to service”, “point ofservice” or “post service” reporting methods cannot achieve. Theembodiments of the invention are intended to facilitate 340B and relatedfunded programs that incentivize healthcare providers to expandmedication access to low-income individuals, families and othervulnerable populations.

In general, many embodiments of the invention provide a computer programproduct that utilizes a safe and secure environment for allowingproviders, pharmacies, and 340B administrators to submit data files foridentification directly relating to 340B claims. The present inventionuses computers to complete the matching, altering, and modification ofpharmacy claims at a speed and efficiency that cannot be achieved byhand based methods.

Such embodiments utilize an exchange clearinghouse that supportssolutions for Managed Care Providers (“MCO”) to identify and report 340Bclaims to the proper administrators. Such a clearinghouse willadminister data and shared savings arrangements with MCOs andparticipating 340B safety net providers, while also creating andsupporting a simplified process for safety net providers, pharmacies and340B administrators, allowing said parties to submit data files for theidentification of 340B claims.

The system and method for processing pharmaceutical funding claims underthe 340B Drug Pricing Program according to the present inventionsubstantially departs from the conventional concepts and designs of theprior art, and in so doing provides a method that offers many advantagesand novel features which are not anticipated, rendered obvious, or evensuggested or implied by any of the prior art, either alone or in anyobvious combination thereof. Many other objects, features and advantagesof the present invention will become evident to the reader and it isintended that these objects, features and advantages are within thescope of the present invention.

While the benefits of the invention are more numerous than mentionedhere, the use of such clearinghouse system creates a seamless solutionfor managed care providers to identify and report 340B claims. Theresulting system allows for a singular streamlined system and other costefficiencies while maintaining the rigid privacy and securityrequirements of HIPAA.

In this respect, before explaining at least one embodiment of theinvention in detail, it is to be understood that the invention is notlimited in its application to the details of the particular methods ofcollecting, processing and reporting certain types of data, nor to theparticular arrangements of components set forth in the followingdescriptions or illustrated in the drawings. The invention is capable ofmany other embodiments and of being practiced and carried out innumerous other ways. Also, it is to be understood that the phraseologyand terminology employed herein are for the purpose of the descriptionand should not be regarded as limiting. While it should be recognizedthat this invention may be embodied in the form illustrated in theaccompanying drawings, the description and drawings are illustrativeonly, and numerous changes may be made in the specifics illustrated ordescribed.

BRIEF DESCRIPTION OF THE DRAWINGS & EXHIBITS

The present invention will be more fully understood by reference to theaccompanying drawings and exhibits, which are for illustrative, notlimiting, purposes. The detailed description of some embodiments of theinvention will be made below referencing to the accompanying figures.

FIG. 1 represents a diagram depicting the preferred embodiment of theClearinghouse specifically detailing the directional flow of data,reports and cash through the system, as well as various 3rd party andgovernmental agencies that interact with the clearinghouse system.

FIG. 2 portrays an exemplary high level overview illustration of aclearinghouse system that facilitates the processing of claims under the340B prescription rebate program, and embodies many aspects of thepresent invention.

FIGS. 3A and 3B together portray an exemplary a High Level TechnicalArchitecture of the ETL process and a diagram illustrating an exemplaryData Flow Diagram of the claims processing system, respectively. Datacontaining claims under the 340B prescription rebate program, and otherimportant internal information, is imported and extracted from multitudeof origin sources, transformed within the system and output files andreports are created once the ETL is completed successfully.

FIG. 4 depicts a standard schematic during the ETL process of bothmaster and child packages located in one environment that is stored inthe SSIS catalog.

FIG. 5 illustrates an example overview of a system server architecturethat facilitates the server performance and capabilities. The multipleSQL servers protect the data from corruption as the data is collected,validated, processed and managed as part of a pharmaceutical rebateprogram.

FIGS. 6A and 6B—Portray various aspects of the systems compliance withHIPAA regulations. FIG. 6A is an illustration of an embodiment of thepreferred database encryption method. In addition to the security, thepreferred embodiment also maintains a log depicting all errors thatoccurred during the data processing, as portrayed in FIG. 6B.

FIGS. 7A, 7B, and 7C—FIG. 7A depicts how one securely logs into thesystem to generate and send out miscellaneous reports. Specifically,FIG. 7A illustrates a block diagram of the SQL Reporting services (SSRS)as it generates reports for the system and how Reporting servicerequests are handled through the components of SSRS architecture.Similarly, FIG. 7B depicts the reporting services architecture infurther technical detail including a three-tier system for securelyrequesting and accessing reports, generated by the system. FIG. 7Cportrays the various SSIS configuration options the administrator canperform.

FIGS. 8A and 8B, together, provide a representation of data partitioningin efforts to maintain data integrity throughout the ETL and dataprocessing. Specifically, FIG. 8A is a flowchart portraying howpartitioning will distribute the data across multiple file groups,thereby preserving data integrity. FIG. 8B is an illustrative diagram ofhow the partitioning is designed to preserve data integrity whilemaintaining performance throughout the system.

FIGS. 9A, 9B, 9C, and 9D portrays an exemplary flowchart depicting howpreferred embodiment processes information. Specifically, the flow chartShows the importation, validation and processing of the clearinghousesystem

FIGS. 10A and 10B illustrates an example of the “Entity” and “MCO” webportals, respectively, of a preferred embodiment. Each flow chartillustrates the preferred method that Entities; MCO's and theirrespective Administrators access, view and interact with theclearinghouse system, as it provides all Shared Savings Statements andInvoices in a user-friendly mode.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

With reference to the accompanying drawings, contemplated best modes andpreferred embodiments of the invention will now be described in moredetail. Although the description provides detailed examples of possibleimplementations of the present invention, it should be noted that thesedetails are intended to be exemplary and in no way delimit the scope ofthe invention. The figures are not necessarily to scale or in asequential order. Further, some features may be exaggerated or minimizedto show details of particular components. In other instances, well-knownmaterials or methods have not been described in detail to avoidobscuring the present invention. Therefore, specific structural andfunctional details disclosed herein are not to be interpreted aslimiting, but as a basis for the claims and for teaching one skilled inthe art to variously employ the present invention. Embodiments of theinvention may include various systems, processes, methods, andapparatuses for the identification and reporting of 340B claims.

When used herein, the following terms, acronyms, definitions, andabbreviations take at least the meaning explicitly associated herein,unless the context dictates otherwise. The meanings identified below donot necessarily limit the terms, but merely provide illustrativeexamples of the terms. The abbreviation “MCO” refers to a Managed CareOrganization(s). When a person decides to enroll in Family Care, thatperson becomes a member of a Managed Care Organization (MCO).

The term “Entity” refers to hospitals and clinics. Under HIPAA PrivacyRules, the term “Covered Entity” refers to three specific program groupsincluding: healthcare plans, healthcare clearinghouses and healthcareproviders that transmit health information electronically. The receiveddata from Entities is imported into the system, processed, validated,and either approved or denied.

The abbreviation “WAC” stands for Wholesale Acquisition Cost. This is apublished catalog which contains the manufacturers' list price for adrug product to wholesalers as reported to the First Databank. Anothercommon abbreviation, “AWP” refers to Average Wholesale Price. This is aprescription drugs term referring to the average price at which drugsare purchased at the wholesale level. The AWP price is used to determinethird-party reimbursement throughout the health care industry becausethird party payers have no other reliable method of obtaining realmarket prices. Both WAC and AWP are similar; however, individual Stateprocedures vary, as each state uses one notation over the other.Therefore, the preferred embodiment utilizes both WAC and AWP standardsin its clearinghouse dependent on each individual State procedure.

The term “clearinghouse” often refers to an organization that collectsand processes information about numerous transactions. As used in thesedescriptions, the “clearinghouse” term refers to a computerized serviceor system that functions to electronically receive information aboutnumerous claims, for further processing of that information to helpusers manage payments and/or credits for those claims. Hence, a 340Bclearinghouse in this context is a computerized system or service thatprovides a common portal for electronically receiving data relevant to340B claims and that systematically processes that data for the benefitof healthcare providers, practitioners, pharmacies, and MCO's. Referenceto the “Claims Processing Solution” relates to the invention and itsmany embodiments as a whole, as it refers to the process that claims areprocessed through for the various medical providers, insurancecompanies, and patients.

The following computer variables and abbreviations have the followingmeaning unless otherwise indicated: “SQL” refers to a special purposeprogramming language known as Structured Query Language, designed formanaging data held in a relational database management system. “SSIS”stands for the SQL Server Integration Services. The primary function forSSIS is data warehousing, as the product features a fast and flexibletool for data extraction, transformation, and loading (ETL). “ETL”refers to an Extract Transform and Load. “SSRS” refers to an SQLReporting Services. “SMTP” refers to a Simple Mail Transfer Protocol.“API” refers to an Application Programming Interface. “SAN” refers to aStorage Area Network. “RAID” refers to a combination of multiple diskdrive components that merge into a single logical unit of memory for thepurposes of data redundancy and improved performance. “IO” refers toInput and Output of the system.

Where databases are described herein, it should be understood by one ofordinary skill in the art that alternative database structures to thosedescribed may be readily employed and other memory structures besidesdatabases may be freely implemented. Further, it is readily apparentthat the various methods and systems described herein may be implementedin part by appropriately programmed General Purpose Computing Devices.Typically a processor (e.g., a microprocessor) will receive instructionsfrom a memory or like device, and execute those instructions, therebyperforming a process defined by those instructions. Further, sets ofinstructions that implement such methods and algorithms may be stored asprograms and transmitted using a variety of known media.

In general, the preferred embodiment is an internet based exchangeclearinghouse to support solutions for MCO(s) and Entities to identifyand report 340B claims. The applicants' HIPAA compliant clearinghouseprovides a platform that collects MCO and approved claims transactions,provides data administration, shared savings processing, and compliancereporting services. In many best practice and hosting areas, thisclearinghouse system leverages other claims processing systems, such as,most preferably, the applicant's Cumulus offering that is commerciallyavailable from applicant.

Reference is now made to FIG. 1 for a diagram depicting the preferredembodiment of the clearinghouse, in which it specifically details thedirectional flow information through the system. The focal pointpreferred embodiment as portrayed in FIG. 1, is the internalClearinghouse system, 100, which monitors and manages the collection anddissemination of information. Specifically, in FIG. 1, the Clearinghousesystem, 100, receives and exports information pertaining tomiscellaneous data, various reports, and financial matters, as theinformation is distributed throughout the preferred embodiment.

The term “Data Flow”, as used in diagram as portrayed in FIG. 1, is ageneric term used to explain various types of data being distributedthrough the system. Initially, the Data Flow, claims are imported to theclearinghouse, 100, from the Managed Medicaid Administrator, 104 andeither Entities, 106 or their 340B administrators, 108. The ManagedMedicaid Administrator, 104, distributes all of the 340B claims to theClearinghouse, 100. The Clearinghouse, 100, collects claims, matchesand/or processes them and then disseminates invoices to the variousEntities, 106, that contract with and utilize the clearinghouse system.Entities, 106 as depicted in FIG. 1 refer to: Federally Qualified HealthCenters, Disproportionate Share Hospitals, and the like. Further,Entities, 106, which contract to use the Clearinghouse system or their340B administrators, 108, receive detailed feedback on claim matchesfrom the Clearinghouse system, 100. Approved claims come toClearinghouse system, 100 and system matches them to MCO data. In someembodiments, these Entities, 106, may forward the Feedback reports tothe 340B Administrator, 108, in order to receive approval of theprocessed claims. Entities, 106, will receive approval from the 340BAdministrator, 108, and forward the approved claims to theclearinghouse, 100, for the Clearinghouse to process. The feedbackReport is discussed in further details below.

The lines demonstrating the directional flow of Reports, relate to bothReports and contractual relationships between parties. The ManagedMedicaid Administrator, 104, is in a contractual relationship with theclearinghouse, 100. Similarly, various Entities, 106, are in acontractual relationship with the Managed Medicaid Administrator, 104.The 340B Administrator, 108, and the Entity, 106, are bound by certainrules which control the dataflow, 120, between them. The Clearinghouse,100, exports a report to the Managed Medicaid Administrator, 104,detailing shared savings statements on matched records. Managed MedicaidAdministrator, 104, gives a report to the State, 102, in which the claimoriginated.

The Final aspect FIG. 1 portrays is Cash Flow, 140. Pharmacies, 110, payeither Entities, 110, or the 340B Administrator, 108. If the Pharmacies,110, pay the 340B Administrator, 108 then the 340B Administrator, 108,pass the rebate or plan savings directly onto the Entity, 106. Uponcompletion of processing the Shared Savings Statements, theClearinghouses, 100, forwards the Shared Savings Statements to theManaged Medicaid Administrator, 104. Clearinghouse, 100, issues invoicesto the entities 106 for the amount owed to Managed MedicaidAdministrator, 104. Entities 106 transfer those funds to Trust accountwhich are in turn sent to Managed Medicaid Administrator, 104 on anagreed upon frequency.

Reference is now made to FIG. 2 which depicts the overall architectureof the preferred embodiment of the 340B Clearinghouse. The depictedsystem is built around the following ancillary components: (1) AProcessing Engine, 203, (2) A Customer Portal, 204, (3) Reportingcapabilities, accessible through the Customer Portal, 204, and (4) AnAdministrative Interface (not shown).

The Clearinghouse Database as portrayed in FIG. 2, 205, is the focalpoint of this illustration. Applicant's Clearinghouse Database, 205,functions as an intermediary as it acquires information from multiplesources, manipulates said information and outputs the information to berepresented to applicant's customers, via the Customer Portal, 204 orvia backend reports. Applicant's clearinghouse leverages a processingsystem such as, most preferably the Microsoft (et. al.) developmenttechnology stack for the Processing Engine, Customer Portal andsynchronization with Salesforce or other Interfaces for customerconfiguration.

FIG. 2 portrays both MCO's, 201, and Entities (Hospitals/Clinics), 202or their 340B Administrators, submitting Medicaid claims data andapproved claims data, respectively, to the applicants Processing Engine,203. The preferred embodiments Processing Engine, 203, includes loadingall inbound files, writing/sending outbound files, integrations to othersystems (e.g., Salesforce, claim data) via DB, claims matching andevaluation. Varieties of options are configurable on acustomer-by-customer database, and are stored in the applicantsClearinghouse processing database. The Processing Engine, 203, thensends said information to the Clearinghouse Database, 205.

The embodiment portrayed in FIG. 2 contains a Customer Portal, 204,which allows both MCOs and Entities to each access their own individualportal to view, in real-time, 340B approved and matched claims, rolledback transactions, and various static and dynamic reports. The CustomerPortal, 204, is a web-based module using, most preferably, the .netframework (ASP.Net/MVC or like) and connects to the Clearinghouse SQLServer database to provide up to the minute claims matching status, andshared savings reporting. Through this configuration, this systemprovides access for multiple user levels, and can access User AccountInformation, Shared Savings Summary statements, Shared Savings DetailedBreakdowns, Claims Search, organization specific user administration,and dynamic reporting. Further, this embodiment of the applicantsClearinghouse solution leverages the same Peer1 environment structurethat is leveraged by the Cumulus solution. Detailed illustrations anddescriptions of the various embodiments of both the MCO and EntityCustomer Portals are represented in FIGS. 10A and 10B respectively.

The Reporting component is accessed through the Customer Portal, 204.Available reports are dependent on a multitude of factors, such as:whether the customer is an MCO or Entity and the level of access grantedto the individual user. Reports are developed using the SSRS as well asvarious stored procedures. A detailed explanation and diagrams of thepreferred embodiment of the customer portals are discussed and found inFIGS. 10A and 10B.

The Administrative module, not shown in FIG. 2, is an internal onlyinterface that allows the applicants business implementation team tosetup variable parameters for a customer to ensure that processingaligns with contractual terms. The module also provides tools to supportimplementation quality assurance and customer service. Thisfunctionality leverages the Salesforce Interface, 210, to manage thedata, and the Microsoft stack and the Salesforce API to replicate datainto the applicants Clearinghouse Database for use by the processingengine.

As noted above, the preferred embodiment of applicants Clearinghouseintegrates with external technology and data sources in several ways.The first external sources of information are Text file and/or EDI filetransfers from MCOs, 201 and Entities, 202. A second source of externalinformation is received from a custom DLL for real-time integrationbetween the clearinghouse and external sources, 206, such as WAC, AWP,COGS, Medispan data, etc. The multitude external Data Sources, 206, areinputted into the External Data Replication Engine, 7, where the data isreplicated and later imported into the Clearinghouse database system forprocessing. The final source of external information originates from aseparate DLL to facilitate data sharing with Salesforce system, 208.Salesforce has an existing API to allow data transfer into and out ofthe Salesforce instance, and SSIS automation provides non-real timecritical data transfers. The Salesforce system, 208, is made up of adatabase, 209, and the salesforce interface, 210. The information isreplicated and imported into the system through the Salesforcereplication Engine, 211.

The architectural design of the preferred embodiment is portrayed by thecomponent description coupled with a technical description whichclarifies the claims processing solution. More particularly, thedescribed embodiment utilizes an Extract/Transform/and Load (“ETL”)structure as it integrates data from multiple applications and sources.Generally, an ETL process extracts data from outside sources, thentransforms it to fit the needs of the overall system, then loads it intothe end target (most preferably a database). Thus, the ETL solution forthe claims processing, of the present embodiment, embraces both designand technical details. The system for claims data processing isdeveloped using, most preferably the SQL Server 2012, or a similarproduct that is commercially available. The various components withinthe SQL Server are primarily used for developing a scalable andefficient solution which includes the SSIS, SSRS and database engine.The SSIS is primarily used for the data load and transformation (ETL).Whereas the SQL Server database engine will be used to applying the corebusiness logic, data storage as well as for archiving purposes. The SSRSis used for sending the MCO statements via email delivery and additionalreports are created and developed for applicant's users which areaccessible from backend and/or on the web.

The preferred embodiment of the claims processing solution is designedto handle a large volume of data efficiently and seamlessly to handlethe ever increasing amount of data. Therefore, the SSIS packages aredeveloped by leveraging the power of SQL Integration Services and alsothe highly efficient SQL Server database engine. The primary use of SSISwill be in importing the data from the FTP, decryption, data validationand transformation. At the same time the Claims processing system reliesheavily on the SQL Server for performing the complex calculations andbulk updates. The preferred solution uses the SQL Stored procedures inmany situations in order to achieve a better performance.

The preferred embodiment is developed using the optimized SQL queries,properly designed indexes, making sure various processes are distributedto avoid heavy load in the database engine on a particular time andefficiently designed table partitioning to minimize the query time. Alsodatabase files will use different RAID configurations for storing datato improve the IO performance.

A claims ETL process extracts data from various input sources. FIG. 3Aportrays two input source Flat Files from Entities, 322, and MCO's, 321and Lookup Data. The flat files reside in a FTP location whereas thelookup data resides in the SQL Server database. Next, the transformationstage is where the data goes through several validations andcalculations. Finally, there will be several output files and reports aspart of the process once the ETL is completed successfully. Such OutputReports are: Feedback Reports, Approval Reports, Shared SavingStatements, Invoice Reports, Reclassification Report, and FileProcessing Detail Report as represented in FIG. 3A, 313 and FIG. 3A,313. The SQL Server Integration Services will also utilize the ETLpackages using SSIS for data movement, validations and transformations.FIG. 4 portrays how the SQL server integrates with various systems, datamovement and transformations. Specifically, FIG. 4 depicts a schematicof master and child packages, during the ETL process, as allconfigurable parameters are stored in one environment within the SSIScatalog.

FIGS. 3A and 3B are used in tandem to portray an exemplary data flowdiagrams depicting ETL process as the data moves through the preferredembodiment of the claims processing system. FIG. 3A portrays anexemplary block illustration of Data Flow through the system. The MCOand Entity flat files, 321, 322 respectively, are copied from the FTPlocation, 320, and kept in the SQL1 server, 520, in a Temporary folder.Also, a copy of the encrypted file is created and kept in a separate FTParchive location, not shown in drawings. The system will decrypt thefile, 323, and start data validation, 340. The Data valuation stagevalidates the data and rejects all non-conforming data. The datavalidation process is discussed in further details below. Then all ofthe properly validated data is transferred to SQL1 Staging server forfurther processing. The final processed data is stored in the SQL 1“CRXProd” database, 526. The reporting data is then transferred from theSQL1 Staging Data Processing Database, 520, particularly, “CRXProd”,526, to the SQL2 database, 530, particularly, “CRXReports”, 534, wherereports are generated. A separate database is used to prevent corruptionof the data when reports are generated. Finally the system generates allthe reports from “CRXReports” database, 534.

Correspondingly, FIG. 3A depicts the preferred embodiment of the highlevel architecture of the technical parameters. Generally, the sourcedata, 320, from both MCO's, 321, and Entities, 222, is decrypted,validated, transferred for processing to SQL 1, 520, then the reportdata is transferred to SQL 2, 530, where finally the output data isplaced in the Reports Database, 313.

As portrayed in FIG. 3A, the preferred embodiment of SQL 1, 520, is madeup of three different files, are “CRXStaging” 522, “CRXAuditLog” 524,and “CRXProd”, 526. The staging server, CRXStaging, 522, is made up of atable which simply contains an (1) Index, (2) Schema Name, (3) TableDescription and a (4) Table Name. The “CRXStaging”, 522, contains twoseparate indexes, one containing inputs for MCO's while the other is forEntity inputs. Each index relates to data corresponding to a specificMCO or Entity. The Schema Name is special schema known as “dbo”(database-owner). The Table Description is a rough description of thetable to easily identify it (i.e. Input validated data coming from flatfile). The Table Name is merely the name of the table, for simplicitythe preferred embodiment names the tables Input_MCO, and Input_Entity.Each index in the Staging Server, CRXStaging, 522, for the MCO, andEntity contain input information for both MCO's and Entities, such as(1) Date Time Stamp, (2) BIN Number, (3) Processor Control Number, (4)Service Provider ID, (5) Transaction Code, (6) Date of Service, (7)Patient First Name, (8) Patient Last Name, (9) Patient Gender, (10)Other Coverage Code, (11) Prescription Reference Number, (12) FillNumber, (13) Provider Service ID, (14) Quantity Dispensed, (15)Transaction Response Status, (16) Total Amount Paid, (17) Patient PayAmount, (18) Dispensing Fee Paid, (19) Switch Indicator, (20) Group ID,(21) File Type and Version, (22) Validate Medication for Clearinghouse,(23) COGS, (24) State, (25) ETLID, (26) Modified Date, (27) RejectionCode, (28) Rejection Description and similar inputted information.

The proposed SQL 1 server, 520, contains a Production Table, hereinreferred to as “CRXProd”, 526. The Production Table, “CRXProd”, 526,receives the data from the Staging tables, 522, for processing. Thepreferred embodiment of the “CRXProd”, 526, contains 25 separate indexeswhere each index contains a (1) Schema Name, (2) Table Name and a (3)Table Description. The Schema Name is special schema known as “dbo”(database-owner) or an Admin. The Table Name is the name of each nestedblock of information contained within each index. The Table Descriptionis a rough description of the index/table name to easily identify it.For example, in this embodiment, table descriptions (without the nestedinformation) are: Medicine and Pricing Details; State and MCO with Shareof State; Pharmacy Allowance Details; MCO and Entity Contract Details;Tiered Pricing Breakup Details; MCO configuration Details; EntityConfiguration Details; Rejection Codes; Various information regardingthe Claims processing for both MCO's and Entities; ArchivingConfiguration; Details on how output report is delivered (i.e., FTP orEmail delivery); Details about the shared saving split percentage; bothMCO and Entities approved data, invoice data, rejection retails; bothMCO and Entities Feedback reports; both MCO and Entities approvalreports; and Reclassification data.

Within each index contained within “CRXProd”, 526, is nested informationstored for later creating the reports. For example, within the firstindex titled “Medicine and Pricing details,” the nested informationcontained within it includes such information as: COGS ID, themedication Name, NDC Number, Cost Type, Cost, Is Branded, Start Date,End Date, and Modified Date. Correspondingly, each index within,“CRXProd”, 526, contains a separate nested block of information.

The last database contained within the preferred embodiment of the SQL 1server, 520, is an Auditing Log. In this illustration it is referred toas “CRXAuditLog”, 524. Information from the CRXProd, 526, is transferredto both CRXAuditLog, 524, and to SQL2, 530. The Audit Log functions ofthe SQL1, 524, deal directly with the security of the system. Thepurpose of these auditing tables is to capture all the necessaryinformation which is part of feedback report. This feedback report issent out to Entities and MCO's every time on every successful executionof claims data processing. The feedback Report is discussed in furtherdetails below.

The data is transferred from the SQL 1 server, 520, to the SQL 2 server,530, to prevent compromising or degradation of data as the reports arecreated. The proposed SQL 2 server, 530, also contains a ProductionTable, where in this illustration it is referred to as “CRXReports”,534. The preferred embodiment of the “CRXReports”, 534, contains nineseparate indexes where each index is described by a (1) Schema Name, (2)Table Name and a (2) Table Description. The Schema Name is a specialschema known as “dbo” (database-owner). The Table Name is the name ofeach nested block of information contained within each index. The TableDescription is a rough description of the index to easily identify whatinformation it contains. Contained within each index is nestedinformation which is collected and stored for later processing thereports. For example, in this embodiment, table descriptions (withoutthe nested information) are: MCO Feedback Report Data; Entity FeedbackReport Data; Entity Approval Data; MCO, Approval Data; ReclassificationsReport Data; and various Admin data dump for—State details, Claimsdetails, and Entity details.

Within each index contained within “CRXReports”, 534, is nestedinformation stored for later creating the reports. For example, withinthe first index, “MCO Feedback Report Data, the nested informationcontained within it includes such information as: Date Time Stamp, BINNumber, Processor Control Number., Service Provider ID, TransactionCode, Date of Service, Patient First and Last Name, Patent Biographicalinformation (Date of Birth, Gender etc.), Other Coverage Code,Prescription Reference Number, Fill Number, Product Service ID,Prescriber ID, Quantity Dispensed, Transaction Response Status, TotalAmount Paid, Patient Pay Amount, Dispensing Fee Paid, Switch Indicator,Group ID, COGS, State, Status of Claim, and etc. Correspondingly, eachindex within, “CRXProd”, 526, contains a separate nested block ofinformation.

Additionally, the SQL 2 server, 530, contains a database called“CRXArchive”, 536. This database contains all archived data coming fromthe main MCO and Entity claims data table as a duplicate to prevent datadegradation.

FIG. 5 portrays the preferred server architecture which represents thetechnical platform for the system. The FTP Server, 510, comprises bothInput and Output files. Additionally, files archiving is also stored inFTP server. The SQL 1 server, 520, comprises Integration Services forrunning the ETL packages, staging, auditing, and logging and productiondatabase. The proposed file names on the SQL 1 server, 520, are“CRXStaging”, 522, “CRXAuditLog”, 524, and “CRXProd”, 526, the substanceof each file is discussed above. The Reports data is further moved tothe SQL 2 server, 530, for reporting purpose. The SQL 2 server, 530,will be hosting the SQL Services Reporting Server along with theReporting database. The reason for separating the Reporting Server intoanother instance is making sure Reporting is separated from the dataprocessing activities preventing no performance degradation whileaccessing or delivering the reports. In addition, all the reports willbe using this server as a data source. The proposed file names of the 4files contained in the SQL 2 server are “CRXReports,” 534, “CRXArchive,”536, “ReportServerDB”, 536, and “DBBackUps”, 537.

FIG. 7C portrays an embodiment of the SSIS Deployment. The Claimsprocessing solution will be using the most preferably the new SQL Server2012 SSIS Catalog deployment feature, or a similar available product.All the SSIS packages will be deployed in a fully secured SSIS catalogdatabase. In the catalog database the administrators will have optionsto change the SSIS configuration details.

Additional components of the preferred embodiments' security include thefile security/data encryption, the SQL Server Integration Services,Logging & Error Handling, Auditing, SSRS and Email Subscriptions, DataPartitioning, and Database Archiving.

The preferred embodiment utilizes six separate protocols for security,to meet or exceed HIPAA requirements. To be HIPAA compliant, thepreferred embodiment utilizes such behaviors as: SQL Authentication,Windows Authentication, Auditing, Confidentiality, Data integrity, andBackup.

The aforementioned six protocols which control the security andmaintaining of HIPAA regulations in the preferred embodiment are simplyillustrated here with a full detailed discussion to follow. TheAuthentication of both SQL and Windows are native to their prospectiveprogramming. The system will have an Auditing function, 524, whereinboth the database and sever instance logs will be created and stored ona separate physical device. Confidentiality is maintained as thesensitive database, “CRXProd”, 526, will be encrypted. Data integritywill be maintained as data sent across the network cannot be modified bya tier. Finally, database backups will be created and stored on aseparate physical device. To facilitate secure communications betweenthe SSIS packages and SQL 1 server and between the SQL 1 server and theSQL 2 server, the preferred embodiment will utilize both the SQL Serverand Windows authentication. Under the SQL Server Authentication one mustlog in using the required username and password. The WindowsAuthentication uses an integrated active directory which does notrequire password.

The internal auditing system of the preferred embodiment possessestables of data stored under the data base called “CRXAusitLog”, 524. Aspreviously discussed the purpose of the auditing tables is to captureall the necessary information which is part of feedback report.

Data integrity is maintained throughout the ETL and data processing.Specifically, the solution uses all the configuration information likeFTP location, file decryption key, MCO and Entity setup information fromthe SQL Lookup tables in SSIS packages. This will make sure any changeshappened in the lookup data will automatically be reflected in SSISpackages without any change in the code.

Another means of preserving data integrity in the preferred embodimentis by utilizing a strong data partitioning component. FIGS. 8A and 8Bportray an illustration of the Data Partitioning component of thepreferred embodiment. The preferred embodiment of the claims processingsolution coupled with the SQL Server partitioning features confirms thatthe solution is scalable to handle large volumes of data. The tablepartitioning will distribute the data across multiple file groups. Thepreferred Embodiment partitions the data horizontally so that groups ofrows are mapped into individual partitions. The table partitioning willhelp in transferring the data quickly and efficiently resulting inbetter query performance.

The preferred embodiment of the claims processing solution has a dataarchiving functionality in place to make sure historical data isavailable in storage area network (hereinafter referred to as “SAN”).The incremental archiving solution will be implemented in SQL Serverwhich will move the old data from main tables to the archive tables inregular predetermined intervals. At the same time, the data in thearchived tables will always be accessible whenever needed. The dataarchiving will make sure a particular table is not too big in terms ofnumber of rows, relating directly to limiting the size of a file, andhence will help in improving the overall 10 performance.

The file encryption utilizes PGP encryption or a similar product that iscommercially available at the time, for encrypting and decrypting thefile. The preferred embodiment encrypts the input files with thedecryption key stored in the database. The SSIS will be used to decryptthe file before it starts processing data. The output files are againencrypted before moving to the FTP location.

SQL Server uses encryption keys to help secure data that is stored inthe server database. FIG. 6A is an illustration of an embodiment of thepreferred database encryption method in compliance with HIPAAregulations. This embodiment will implement the database levelencryption for some of the databases where the sensitive information isstored, specifically, the “CRXProd” and “CRXArchive” databases will beencrypted. The encryption includes encrypting the data, log files andthe backup files. The claim processing solution will use the SQLServer's transparent data key encryption (TDE) technique (as portrayedin FIG. 6A), or a similar product that is commercially available, forencrypting the SQL Server database, log and backup files. TDE performsreal-time I/O encryption and decryption of the data and log files. Theencryption uses a database encryption key (DEK), 610, which is stored inthe database boot record. The contents of this boot page are notencrypted; thus the DEK, 610, has to be encrypted by using acertificate, 620, stored in the key server, 630. After it is secured,the database can be restored by using the correct certificate. Thus, onopening the encrypted databases the SQL Server first opens up the bootpage, which contains the DEK, 610, then it finds the certificate, 620.Once the certificate, 620 is located, it can then be used to decrypt theDEK, 610. Finally, this decrypted DEK, 610 is used to decrypt the actualdata pages as they are read from and written to disk.

In addition to the security, the preferred embodiment also maintains alog depicting all errors that occurred during the data processing. Thepreferred embodiment of the Claims process solution will log each andevery event while the ETL is running. The logged data will be stored inSQL Server under the “CRXAuditLog” database, 524. This database willalso capture the warnings and error messages in case of any problems.The purpose is to make sure that any ETL issues are easily traced backby the server admins. As previously mentioned the “CRXAuditLog”database, 524, is used for capturing audit information, under adifferent schema name, for the feedback report. The FIG. 6B depiction ofhow the system logs errors. Starting with the source information, 650,the data is converted and processed during the data conversion stage,660. Once the data is converted to the proper format, as utilized by theembodied system, one row of data at a time is checked to verify noerrors exist. If the row is error free, it is moved to its properdestination, 670. However, if the row of data contains an error isplaced in the error log, 675.

The solution will send email notifications to administrators every timethe ETL runs. These notifications are an acknowledgement of a successfulETL execution and include any failures if they occur. Errors will bekept in a separate error tables. The ETL solution knows where to startthe process next time it runs in the case any failure occurred. Thepurpose is to make sure data is not corrupted in the case that the lastETL process did not run successfully completely.

FIGS. 7A and 7B depicts the SSRS and Email Subscriptions and the SSRSNative Mode Deployment as utilized by the preferred embodiment. SSRS isSQL server based report generation software manufactured by Windows. Thepreferred embodiment uses SSRS for generating and sending out SharedSaving Statements and Invoice reports; however any similar softwareproduct that is commercially can also be utilized.

Reports are created once the ETL processing completed. These reportswill be sent out to the various subscribed email addresses in either PDFor excel format. Also, few parameterized reports are developed forinternal use of applicant users which could be accessed on the web. SSRSuses fully secure Http sys protocol making sure reports are secure whenaccessed in the web. FIG. 7A illustrates a block diagram of the SQLReporting services (SSRS) as it generates reports for the system;specifically, how Reporting service requests are handled through thecomponents of SSRS architecture. All requests are received by theReporting server's operating system through HTTP.SYS Driver, 710.HTTP.SYS routes the communication directly to the Reporting ServicesWindows Service, 700, which handles all on-demand, interactive reportprocessing. Once, the communication is within Reporting Services WindowsService, 700, the HTTP.SYS Driver, 710, routes the communication to thereporting service's Web service, 716. HTTP Listener, 712, receives therequest which is rerouted by HTTP .SYS, 710. HTTP Listener, 712,transfers the request to Security sub layer (SSL), 714, forauthentication. Once a user is authorized by the SSL, 714, the usercommunication is redirected to either Report Manager, 715, or ReportServer, 716, which is hosted in the Reporting Services web services,716. Report Manager, 715 and Report Server, 716, read the reportdefinition, report details like parameter, etc. with the assistance ofthe Core Processing unit, 718. Further, the Core Processing Unit, 718,conducts the report processing, and subscription management. Uponcompletion of the report processing of the SSRS, the report outputtransferred to the Reporting Services Database, 720, and is then isrendered on a report viewer. The Report Server Database, 720, is a SQLserver database which is used as a data dictionary about reports.

FIG. 7B depicts the reporting services architecture in further technicaldetail. The diagram portrays a three-tier system of a reporting servicesdeployment as well as the flow of requests and data among the variousserver components. The three tiers of the FIG. 7B are: the presentationtier, 750, which contains the client applications and custom tools; themiddle tier, 760, which is comprised of the report server components;and the Data Tier, 770, comprising the report server database, 720, anddata source, 775.

The presentation tier, 750, encompasses the client external applicationsand custom tools in creating the report. The middle tier, 760, is a webinterface for managing and generating various reports. The reportManager, 715, is a browser application that provides front end access toa user, granting the user access to the reporting service web service,as depicted in FIG. 7A. The Report Processor, 761, receives the requestfor a particular report, which includes the desired formatting andparameters to be included in the report. The Report Processor, 761, thenretrieves all report data and preforms all necessary processing andtransformation on the data. Various extensions, are be added to thesystem to support the data processing and report generation. TheAuthentication Extension, 763, is a security protocol as itauthenticates and authorizes users to a report server. The ReportProcessing extension, 764, is optional as it provides custom reportprocessing fro report items. The Rendering Extension, 765, transformsthe data layout from the report processor to a device specific format(i.e. —Microsoft Excel, PDF, Microsoft Word, etc.). The Data ProcessingExtension, 766, is used to query a data source and return a flattenedrow set. The Schedule and Delivery Processor, 767, uses the DeliveryExtension, 768, to deliver reports to the defined output. Through theDelivery Extension, 768, reports are to deliver to various locations(i.e. email, a specific location, etc.), based on the users subscriptionto the reports. The final tier as depicted in FIG. 7B contains theReport Server Database, 720, and the Data Source, 775.

The various embodiments of the claims processing solution encompasscertain directives that control the flow of information and dataprocessing as the system identifies and reports 340B claims for bothMCO's and various Entities. FIG. 9 portrays an exemplary flow chartdetailing the preferred embodiments processing of information. The datainterchange between the MCO's and safety net providers includes, but isnot limited to: approved claims files from MCO and safety net providers;approval for claims to MCO and safety net providers; and reports andinvoices.

The preferred embodiment of the data interchange is built upon ninebasic parameters that govern the system and provide traceability. Thesystems architecture and design is flexible to handle an ever increasingload of processing data as new MCOs and Entities sign up. Secondly, thesystem possesses security and privacy protocols in compliance with HIPAApolicies. Thirdly, the system cross references at least the followinginformation, Effective dated WAC, AWP, Effective dated COGS, and Brandvs. Generic. Next, the system imports and stores incoming filessubmitted by MCOs and Entities containing claims information such as,Validate file inputs, and Filter for duplicates. The system thenprocesses claims data submitted/imported from MCOs and Entities tocalculate shared saving for MCOs and Entities based on specificcriteria: Apply financial, formulary, COGS tolerance failure; Processreversals; and Calculate shared savings. Next, the system createsinvoices and reports based on the calculated shared savings. The reportsand invoices are then sent out to various parties—the reports of all thematches are sent to the various MCOs and to the State; the invoices aresent to all of the Entities; a shared saving statement is sent to theMCO's; and finally, a report on Flagged “Failed Financial Filter”records are sent to the MCO's. The system then Archives and deletes thedata. Finally, the system shall generate two final reports: a ClaimsStatus Report and an Admin Data Dump.

As already described, the preferred embodiment's architecture and designshould be flexible and scalable to handle the load resulting from largeand ever increasing amounts of claims as new MCO's, Entities and safetynet providers sign up across the country. Since many MCO's operate inmore than one state, the processing protocols may vary per State and perMCO.

To ensure data privacy is maintained, the system complies with HIPAAregulations which include data encryption and secure transmissions ofsensitive information. The database is encrypted. To access the databaseand clearinghouse system, all users must pass the secured authenticationprocess. The preferred security protocols to access the system has atwo-step authentication for new users during setup which includes: (1)When a user is set up, an email will be sent to the user to verify hisidentity, and (2) When the authentication link is clicked, the securitysystem shall check the email address and temporary password beforeletting the user set a new password. Additionally, the system shallrequire a strong password (where such features include: 8 characterslong, at least one uppercase latter, at least one character, and atleast one number). After the data import process is complete, the systemdeletes the decrypted incoming claims file. If applicable, the systemalso encrypts files when it sends approval statements, feedbackstatements, shared savings statements and invoices either via FTP oremail. Additionally, the system retains the original encrypted file sentby MCO/Entity for auditing.

To process claims in the clearinghouse, each claim will have to passpre-defined business rules which include: Brand Name Medications,Financial, and Formulary Tests etc. Additionally, medical equipment isincluded in processing claims.

The preferred embodiment relies on external data for cross-referencingand retrieving information regarding Costs of Goods Sold (COGS),Wholesale Acquisition Costs (WAC), brand v. generic, etc. The systemwill cross reference the following information from external sources:effective dated WAC or AWP (depending on the State, when calculatingsavings and viability of the claim); effective dated COGS; and Brand v.Generic.

WAC and AWP information is loaded into the system from an externalsource. This information is stored in the system using effective datesto maintain history and to make sure the correct price is used for crossreference based on date of service for the claim being processed.

The system also, cross references COGS, from an external source, whencalculating savings and viability of the claim. This information isstored in the system using effective dates to maintain history and tomake sure the correct price is used for cross reference based on date ofservice for the claim being processed.

Additionally, the system can cross reference MediSpan data, uploadedfrom an external source, to determine if the claim being processed isGeneric or Brand. The system has the ability to pull data for WAC, AWP,COGS and Band vs. Generic to use for matching engine. The script forpulling data is done on either an incremental or full update mode.

The preferred embodiment imports and stores incoming files containingclaim information submitted by both MCOs and Entities. The systemvalidates the input file, and Filter the files for duplicates.

The system imports and validates the data that is submitted by the MCOs.Initially, the system imports all files available in the respective FTPlocation. To validate the input data, the system will require all inputinformation to be placed in rows. If any row does not match the properformat, then that specific row is rejected. There should be three recordtypes in the file: PA, DE, and PT. There should be a single Header (PA)and a single trailer (PT) each. If there are multiple PA rows or PTrows, then the entire file should be rejected. Once the inputinformation is placed into its proper row, the system confirms all therequired fields are available. If any required field is missing in arow, the row is rejected. For example the preferred embodiments requiredfields are: Adjudication Date, Adjudication Time, Service Provider ID,Date of Service, Prescription Reference number, Fill Number, AdjustmentType, Product Service ID, Prescriber ID, Quantity Dispensed, TotalAmount Paid, Patient Pay Amount, Dispensing Fee, and Group ID.Additionally, the system also validates that all the field data typesand lengths match. Field descriptions and file layouts have thefollowing protocols for data transfer. All files are in a plain textfile with the .TXT extension; however once encrypted, the file may havean optional PGP extension. Fields are separated by the “pipe” character(e.g. “|”); whereas each record is be separated by a new line. If thereis no data for the field that that file will be NULL, denoted by anempty string (e.g. “∥”). If the there is a mismatch for a row, theentire row is rejected. The system shall check for duplicate submissionfor each row in the file being imported for the MCO. The systemidentifies duplicates by matching the following columns: Transaction ID,Service Provider ID, Date of Service, Prescription Reference Number,Fill Number, Adjustment Type, Adjudication Date, and Adjudication Time.If a row is identified as a duplicate submission, that row will not beused for matching against Entity data. Further, the MCO will be notifiedin their feedback report.

Next, the system imports and validates the data that is submitted by theEntity. Initially, the system imports all files available in therespective FTP location. To validate the input data the system requiresall input information to be placed in rows with their columns based onthe I1 File format. If any row is missing any columns, the entire fileis rejected. If the entire file is rejected, then the feedback file (I7)will have only 1 row stating that the file is being rejected because itdoes not match the number of columns expected. For example the preferredembodiments required fields are: Adjudication Date, Adjudication Time,Service Provider ID, Date of Service, Prescription Reference number,Fill Number, Adjustment Type, Product Service ID, Prescriber ID,Quantity Dispensed, Total Amount Paid, Patient Pay Amount, DispensingFee, and Group ID. The system then validates that the field data typeand length match. If there is a mismatched row, that row is rejected.The system then checks for duplicate submission for each ROW in the filebeing imported for the Entity. System shall identify a duplicatesubmission by matching the following columns: Transaction ID, ServiceProvider ID, Date of Service, Prescription Reference Number, FillNumber, Adjustment Type, Adjudication Date, and Adjudication Time. If arow is identified as a duplicate submission, that ROW will not be usedfor matching against Entity data. Additionally, the MCO will be notifiedin the feedback report. Under the preferred embodiment no feedbackreports are combined for file rejections. For example, if an entitysubmits 10 files and 2 files are rejected because of failed validationthe entity will get 8 processed feedback reports and 2 failed feedbackreports for a total of 10 files (which matches the original number ofsubmissions).

Once the claims data from MCOs and Entities are submitted, imported andvalidated, the system then processes the information to calculate sharedsavings for MCOs and Entities. If there is any shared savings it issplit between the MCO and Entity, with the percentage split setup at theMCO level. The system matches records, which have been successfullyimported/submitted by MCO's and Entity's which have not been alreadyprocessed, using primary and a secondary match. The primary filter usedto match a record looks at: Adjudication date, Adjudication time,Service provider ID, Date of service, Prescription reference number andfill number. If the primary filters match then a secondary filter isapplied, which looks at demographics, is applied and reviews: ProductService ID, Prescriber ID, Quantity dispensed. If the record matches onboth the primary and secondary filter, it is considered a successfulmatch. However, if a record matches on primary but not on the secondaryfilter, the row is Flagged but matched and feedback is provided to theappropriate party. System is capable of implementing Primary and/orSecondary match criteria (if required).

The system runs the 4 different filters to determine the amount ofshared shavings for the records that are matched: (1) Brand vs. GenericFilter; (2) Financial Filter; (3) Formulary Filter; and (4) COGS Filter.Under the Brand vs. Generic Filter the system checks if the MCO for theclaim will process generic drugs. If the MCO does not accept generic,that information is flagged for reporting purposes later. The FinancialFilter acts as a simple equation in which the Shared Savings is equal tothe “Total Paid”—“Allowance”—“340B COGS”—“Savings for State”. Under thisfilter the “Total Paid” is defined as the amount submitted by the MCO inthe total paid column and includes the patients co-pay. “Allowance” isdefined either at the MCO level or pharmacy level using the in housepharmacy/special pharmacy value. When setting up a new MCO the“Allowance” value is defined. However when a special pharmacy or anin-house pharmacy is used, an exception will be added later. The “340BCOGS” is provided as an external feed which will be used as a lookup.The “Savings for State” is dependent on the State the claim is from.Some States require certain MCO's to pay a percentage of either WAC orAWP, for all claims as part of their contract. Therefore, this valuechanges depending on the state the claim is from. The information fordetermining the States cut is submitted by the MCO (not Entity). SameStates can have contractual agreements with multiple MCO's, wherein eachMCO has a different State cut setting. Under the Formulary Filter, ifany 340B medication price is not available in the lookup information,the record is flagged. Under the COGS Filter, the system cross checksthe COGS for a claim submitted by the entity to match against the COGSeffective date available in the system. The record will be flagged ifthe COGS do not fall in the range of +/−25%. Additionally, the MCO's donot submit a value under the COGS filter. After the Financial,Formulary, COGS tolerance failure filters are applied, the system thenprocesses reversals. When a claim is reversed, the amounts of TotalPaid, Patient Co-Pay, Dispensing Fee, are reversed and shown as anegative amount. The system then calculates the Shared Savings.

The system then processes a matched claim if it passes the 4 filterseven if there is more than one payer on the claim. The payer isidentified by the column titled, “Other Coverage Code”. The primarypayer is identified by “null”, “0”, or “1”. A secondary payer isidentified by a value greater than 1. The system reviews the recordssubmitted and determines if a claim has a primary or secondary payer.

The system creates one invoices per Entity based on interface 15 andsends the invoice either pre-configured FTP location (specific to thatentity) or email it to a specified user. An Entity will be charged ifthe Applicant fee model for the MCO/Entity relationship is Per Matchmodel. The system creates a report on approval, per each MCO, based oninterface 14 and FTP's the file to the configured location specific tothe MCO. Additionally, the system creates one shared savingstatement/invoice based on interface 15/16, per MCO, and transmits thefile to the configured location specific to that MCO. The service fee isdeducted entirely from the MCO's portion of the shared savings. Thesystem then sends the approval file, either by FTP to an approvedlocation specific to that entity, or by email to a specific user.

The system then archives and deletes data. The system shall retainrecords successfully imported, but not yet matched, in transaction tablefor a configurable amount of time in months before archiving. If a claimis submitted after a secondary configured time, based on the date ofservice the system shall return a flag code of “81” (Record too old.).

Lastly, the system will generate 2 reports, a Claims Status Report andan Admin Data Dump. The Claims Data report is used to determine thestatus of claims and provides details of the claims submitted by MCO andEntity. Similarly, the Admin Data Dump report is used to review the datacurrently used in the clearinghouse-matching engine. Salesforce will beused as Admin front end to administer data. Since Salesforce will beused to administer data for Clearinghouse engine, the system shallmaintain mechanism to sync data between Salesforce and Clearinghouse.Both reports (Claims Data Report and the Admin Data Dump) should besortable and should have the ability to export in other formats (PDF,excel, word).

Both Entities and MCO's have their own individual user interface tointeract with the system. Entity users and administrators, have theability to search and view claims as well as shared savings statements.Additionally, Entity users and administrators are provided a means toview MCO based configuration data and allowed some editing ability toauthorized users login information. Similarly, MCO users andadministrators have the ability to search and view claims as well asshared savings statements. Additionally, MCO users and administratorsare provided a means to view MCO based configuration data and allowedsome editing ability to authorized users login information.

The exemplary interface of the preferred embodiment includes individualweb portals designed for Entities and MCO's, which are comprised ofnumerous components thereby allowing versatility to the user, permittingthe one to search/view both claims and shared savings statements.Equivalent displays or displayable information may further be generatedwith respect to other equivalent interface platforms within the scope ofthe present invention. Various additional display screens may beunderstood as being further generated for the interface of the presentinvention but are nonetheless omitted in the figures shown, without anyimplication or understanding to be drawn from such omissions, suchdisplays including for example user login screens, and data entryfields.

The preferred embodiment comprises five key display screens that assistand allow the user to interact seamlessly with the system. The screenson the web portals for both the Entity users and MCO users are: Login,My Account, Invoice Summary, Claims Search, Administrator, and Reports.However, one of skill in art can appreciate many alternativearrangements and configurations that can be constructed to achievediffering technical and stylistic benefits.

Before either an Entity user, MCO user or their respective administerscan access the system, they must be granted admittance to enter the webportal via logging-in. Upon the user's initial attempt to access thesystem, the system prompts the user to Log In, 810, by requesting ausername and password. If the username and passwords are approved withinthe system the user is granted access to the system and is brought tothe home screen, 820. However, upon failing to enter the correct log-ininformation, the user is blocked from accessing the system, 815.

The preferred embodiment for both Entities and MCO's home screen, 820,are comprised of a navigation bar, 825, which contains five tabs theuser can review. The five tabs are: My Account, 830, Invoice Summary,840, Claims Search, 850, Administrator, 860, and Reports, 870. Thenavigation bar, 825, also contains a prompt which allows the user to LogOut, 890, of the Web Portal, once the user finishes reviewing thedesired information.

The first option on the navigation bar, 825, is titled, My Account, 830.My Account, 830, and its sub-selections, are only visible and accessiblyby the administrator and are pre-populated with the previously inputtedinformation. The My Account, 830, option within the Entity Web Portalhas 2 different selections contained within it, Schedule, 831, andContacts and Relationships, 832. However, the My Account, 830, optionwithin the MCO's Web Portal has 3 different selections contained withinit, Schedule, 831, Fee Structure, 832, and Contacts and Relationships,833. The Schedule screen, 831, (for both Entity and MCO web portal)allows the administrator to view all relevant information and determinewhether or not the certain information is accurate. This screen depictsthe FTP locations for incoming information, invoices and shared savingsstatements, as well as feedback. The information displayed is onlyrelated to the actual Entity that is logged in. The My Account tab, 830,also contains information pertaining to Contacts and MCO Relationships,832. The Contacts and Relationships tab, 832, allows the administratorto view relevant information and determine whether or not theinformation is accurate. This screen contains all biographical contactinformation regarding the Entities or MCO's representative. Further theContacts and Relationships tab, 832, shows all of the MCO relationshipsthat the Entity has and visa-versa, dependent on which partyadministrator is viewing the Web Portal. The MCO web portal contains anadditional selection, Fee Structure, 833, that is not contained withinthe Entity web portal. The Fee Structure selection, 833, under MyAccount, 830, allows the administrator to view various fee structuresand determine if it is accurate. The Fee Structure selection, 833, isdependent on the relationship between the MCO and State. Further, theFee Structure, 833, tab provides a default fee structure and entityspecific fee structures, which are pre-populated. Additionally, The FeeStructure, 833, selection provides the State cut percentages of allStates that the MCO has a relationship with, be it either a negotiatedor standard percentage. The Fee Structure, 833, also includes the AWPand WAC that the State uses to determine the cost of prescriptionaverage cost.

The next option, within the Entity web portal is titled invoice summary,840, which allows the user to view the shared savings statement by bothits number and month. The user can review a list of all invoicestatements which is sortable and includes the invoice number, the datethe shared savings was run as well as the shared savings fee, and theState fee. The user can select and review Invoice Details, 841, of anyparticular invoice by clicking the respective hyperlink button. Thedetails give a complete overview of the services provided andprescription drugs given to a person covered under the 340B program. Forexample, information that is included in the report includes but is notlimited to, the Invoice number, date of service (the date the claim wasmade), a prescription reference number (the number associated with aspecific prescription), fill number (which prescription refill wasfilled), a prescriber ID (either the DEA or the NPI number of thepharmacy), quantity dispensed, product service ID, total paid (the totalpaid by the insurance company and the patient co-pay), 340B dispense fee(the fee charged by the pharmacy for dispensing the prescription), 340Bplan receipts (reflects what was received for the prescription), BIN(refers to the provider identity), Group ID (contains a number that isused to identify a provider), status of claim (depicts whether the claimhas been approved, rejected, pending, invoiced or new), total sharedsavings (reflects the total shared savings that is split between the MCOand entity), and many more. Each grid of information is sortable bycolumn, and has the ability to be exported to various formats—such asPDF, excel or word.

The next option, within the MCO web portal is titled Shared SavingsStatement Summary, 850, which allows user to view the shared savingsstatement by number and month. The Shared Savings Statements Summary,850, lists all shared savings statements, its month, its year, the totalshared savings, and the state fee. Each grid of information is sortableby column, and has the ability to be exported to various formats. Theuser is then able to select an individual Shared Savings statement toview the details, 851, of the particular selected statement. Forexample, information that is included in the Shard Savings statementdetails includes but is not limited to, the entity (the entityassociated with the MCO for this statement), date of service (the datethe claim was made), prescription reference number (associated with aspecific prescription), fill number (specifies which refill it is),prescriber ID (reflects either the DEA, or NPI number of the pharmacy),quantity dispensed, Product Service ID (reflects the product dispensed),Total paid (reflects the total paid by the insurance company and thepatients co-pay), 340B dispense fee (refers to the fee charged by thepharmacy for dispensing the prescription), 340B plan receipts (reflectswhat was received for the prescription), BIN (refers to the provideridentity), Group ID (contains a number that is used to identify aprovider), status of claim (depicts whether the claim has been approved,rejected, pending, invoiced or new), total shared savings (reflects thetotal shared savings that is split between the MCO and entity), and manymore. Each grid of information is sortable by column, and has theability to be exported to various formats—such as PDF, excel or word.

Another option available to the user, both Entity and MCO, on theNavigation Bar, 825, is the Claims Search tab, 860. It allows the userto specify a search criterion to review specific claims in the databasefor the specific Entity (on the Entity web portal) or MCO (on the MCOweb portal) logged-in. The database claims can be filtered based onrelationships that the MCO has with the Entities. A user can specify allEntities or a specific Entity. The search can be further filtered byspecifying a start and end processing date data; or if the user desiresto choose a range they want to search under the Process End Date theytype in the latest date the claim was processed. The process start daterefers to the latest date that the claim was processed. The final filterallows the user to even further refine his search by describing thestatus of a claim. The user can select one or more status such as, New,Approved, Pending, Rejected, Invoiced or All. Finally, once the userselected all the specified search criteria and corresponding filters,the web portal will search the database for claims that meet thecriteria selected by the user and propagate a Claims Detail, 861,listing all claims that met the user selected criteria. The ClaimsDetails Report, 861, lists all information contained within itsdatabases of each claim that matches the search, it is sortable, and hasthe ability to be exported in various formats. For example, informationthat is contained in the Claims Details, 861, includes but is notlimited to, date of service (the date the claim was made), prescriptionreference number (associated with a specific prescription), fill number(specifies which refill it is), prescriber ID (reflects either the DEA,or NPI number of the pharmacy), quantity dispensed, Product Service ID(reflects the product dispensed), Total paid (reflects the total paid bythe insurance company and the patients co-pay), 340B dispense fee(refers to the fee charged by the pharmacy for dispensing theprescription), 340B plan receipts (reflects what was received for theprescription), BIN (refers to the provider identity), Group ID (containsa number that is used to identify a provider), status of claim (depictswhether the claim has been approved, rejected, pending, invoiced ornew), total shared savings (reflects the total shared savings that issplit between the MCO and entity), and many more. The Entities webportal also includes the MCO associated with the entity for thestatement; whereas the MCO web portal includes the entity associatedwith the MCO for this statement.

The Administrator tab, 870, for both the Entity and MCO web portals,allows an administrator to view and edit the Users and send a passwordreset to a user if necessary. Standard users do not have access to thisscreen as it is only accessible and editable by administrator log-in.The Administrator tab has two sub categories, User Edit Screen, 871, andUser Password Reset screen, 872. The User Edit Screen, 871, contains alist of all approved users including their name, user name, emailaddress, account status and their respective role in their company. Oncean administrator is logged-in, the administrator creates new users hereand can edit existing users profile information. Similar to the UserEdit Screen, 871, the User Password Reset screen, 872, allows anadministrator to send an email to a user allowing the user to changetheir password to access the system.

The Final item in the preferred web portal for both Entities and MCO'sis the Reports tab, 880, The Reports tab, 880, gives the user access tofour difference reports including, Summary, Detail, Formulary andRejection. All four reports are available for the user run based ontheir specific criteria.

The Summary Report gives a summary for the user of critical data of theuser's selection. For example, information that is contained in theSummary Report, 880, includes but is not limited to, Entity (user isable to choose from all the Entities the MCO has a relationship with ora single entity), shared savings number (user can select from a list ofshared savings numbers with the entity number), From data (date for whenthe shared savings number was run), to date (user can set the latestdate he wants to run a report), null (if not date is specificallychosen, all dates will run in the report), 340B pharmacy payments, 340Bdispense fees, 340B pharmacy charges, 340B admin fees, 340B planreceipts, Batch #, inventory order date, 340B pharmacy claims payments,340B pharmacy dispense fees earned, other pharmacy charges,administration fees, 340B plan receipts due, and many more. Each grid ofinformation is sortable by column, and has the ability to be exported tovarious formats—such as PDF, excel or word.

The Details Report provides multitude of details for the user regardingvarious information that the user might be interested in. For example,information that is contained in the Details Report, 880, includes butis not limited to, fill date, RX number, fill number, dispense quantity,total paid, allowance, state percentage, administration fee, MCO sharedsavings, Entity Shared Savings, and many more. Each grid of informationis sortable by column, and has the ability to be exported to variousformats—such as PDF, excel or word.

In the preferred embodiment the Formulary Report provides staticinformation regarding the different formularies based on the criteriaselected by the user. Preferably, the user can input up to 4 differentaccounts to run reports against. For example, information that iscontained in the Formulary Report, 880, includes but is not limited to,a description, NDC number, generic brand, package units, multiplierpackages, total NDC units, and many more. Each grid of information issortable by column, and has the ability to be exported to variousformats—such as PDF, excel or word.

The last report in the preferred embodiment is the Rejection Report. TheRejection Report which shows based on certain user set criteria, all ofthe rejections based on specific filter classifications. For example,information that is contained in the Rejection Report, 880, includes butis not limited to, ID, Claim date, Invoice ID, number of claims, andmany more. Each grid of information is sortable by column, and has theability to be exported to various formats—such as PDF, excel or word.

As one of skill in art can appreciate, many other alternativearrangements can be constructed to achieve different stylistic benefitsaccording to the teachings of the present invention. Many variations canbe imagined as a result of these teachings herein, all of which areintended to be encompassed within the invention as claimed except to theextent anticipated by or made legally obvious by the prior art, or tothe extent clearly and unequivocally disclaimed.

Even though the embodiments illustrated and discussed herein representthe most preferred at present, those of ordinary skill in the art willrecognize many possible alternatives that have not expressly suggestedhere. While the foregoing written descriptions enable one of ordinaryskill to make and use what is presently considered to be the best modesof the invention, those of ordinary skill will understand and appreciatethe existence of variations, combinations, and equivalents of thespecific embodiment, method, and examples herein. The drawings anddetailed descriptions herein are illustrative, not exhaustive. They donot limit the invention to the particular forms and examples disclosed.To the contrary, the invention includes any further modifications,changes, rearrangements, substitutions, alternatives, design choices,and embodiments apparent to those of ordinary skill in the art, withoutdeparting from the spirit and scope of this invention, as defined by anyclaims included herewith or later added or amended in an applicationclaiming priority to this present filing. The invention covers allembodiments within the scope and spirit of such claims, irrespective ofwhether such embodiments have been remotely referenced here or whetherall features of such embodiments are known at the time of this filing.Thus, the claims should be interpreted to embrace all furthermodifications, changes, rearrangements, substitutions, alternatives,design choices, and embodiments that may be evident to those of skill inthe art. In any case, all substantially equivalent systems, articles,and methods should be considered within the scope of the presentinvention.

While the present invention is not intended to be exclusively controlledby computer programs or algorithms on the Internet, it is intended thatthe present invention can be implemented and controlled by computerprograms or algorithms over the Internet, or other computer network.Therefore, the present invention contemplates a series of computeralgorithms and method by which the present invention is implemented andcontrolled. Thus, in some of the descriptions herein, the presentinvention is presented partly in terms of process steps and operationsof data bits within a computer memory. An algorithm is here, andgenerally, conceived to be a self-consistent sequence of steps leadingto a desired result. These steps are those requiring physicalmanipulations of physical quantities. In the present invention, theoperations referred to may be automated, machine operations done by acomputer or similar device performed in conjunction with a humanoperator.

The present invention relates to the methods for operating such devices,and processing electrical, magnetic, optic, or other physical signals togenerate other desired physical signals. It further relates to acomputer program and the control logic contained therein. The presentinvention also relates to apparatus for performing these operations. Theapparatus may be specially constructed for the required purposes or itmay comprise a general purpose computer including a non-transitorycomputer readable medium selectively controlled or reconfigured by acomputer program stored in the memory of the computer. Further, becausethe present invention is intended to include a network of participants,with no geographic limitations, it is contemplated that to betterimplement the system of the current invention, at least part of suchimplementation will take place on the Internet, or other computernetwork. The method presented herein is not inherently related to anyparticular computer or other apparatus. Similarly, no particularcomputer programming language is required. The required structure,although not machine specific, will be apparent from the descriptionherein. Additionally, even though a specific device or softwareapplication may, or may not, be mentioned in conjunction with a step, oralgorithm, or action, it is intended that any appropriate device orsoftware application necessary or capable of implementing that step, oralgorithm, or action is anticipated herein. For example, if a step callsfor the input of data, it is contemplated that any appropriate devicessuch as, but not limited to, various input devices, output devices, datastorage devices, data transfers devices, could be used and areanticipated herein.

Although the invention has been described with reference to specificembodiments, this description is not meant to be construed in a limitedsense. Various modifications of the disclosed embodiments, as well asalternative embodiments of the inventions will become apparent topersons skilled in the art upon the reference to the description of theinvention. It is, therefore, contemplated that the appended claims willcover such modifications that fall within the scope of the invention.

What is claimed is:
 1. A system for managing, processing, and fulfillingpharmaceutical funding claims and supply chains, said system comprising:a computer system including a processing engine and at least onecomputer terminal, said at least one computer terminal having at leastone communication line, for remote communication through the internetwith said processing engine; and said computer system being programmedto perform a method for managing, processing, and fulfillingpharmaceutical funding claims and supply chains, said method includingthe steps of: said computer terminal connecting to said processingengine and transferring over said communication line a claim informationfile that has been encrypted; said processing engine decrypting saidclaim information file and validating said claim information file; saidprocessing engine importing said validated claim information file into aclearinghouse database; said processing engine applying, matching andprocessing algorithms to said clearinghouse database to identify claimswith unrealized shared savings; said processing engine creating invoicesfor said claims with unrealized shared savings; said processing engineupdating said claim information file; said processing engine archivingand generating a report reflecting the success or failure of the claimsprocessing.
 2. The system as in claim 1 wherein said claims withunrealized shared savings are offline reversal claims.
 3. The system asin claim 1 wherein said claims with unrealized shared savings arerecreated approved claims with a proper submission clarification code.4. The system as in claim 1 wherein said communication line of said atleast one computer terminal comprises a plurality of communicationmethods.
 5. The system as in claim 1 wherein said processing engine andsaid computer terminal are run on the same computing device.
 6. Thesystem as in claim 1 wherein said processing engine being programmedallows for user interaction.
 7. The system as in claim 1 wherein saidprocessing engine being programmed allows for automated interaction. 8.A method for the management of all aspects of processing and fulfillingfunded pharmaceutical supply chains said method including the steps of:a. receiving pharmaceutical claims from a pharmacy service provider; b.evaluating and matching said pharmaceutical claims to identifypreviously adjudicated pharmacy claims with unfulfilled funding; c.altering, changing, or reclassifying said previously adjudicatedpharmacy claims through a system, outside of and unrelated to the systemused by said pharmacy service provider who adjudicated said previouslyadjudicated pharmacy claim; d. creating a reversing claim of saidpreviously adjudicated pharmacy claim and recreating an altered, changedor reclassified original claim of said previously adjudicated pharmacyclaim.
 9. The method of claim 8 also including the steps of collectingand reporting of accurate quantities of said previously adjudicatedpharmacy claims in which 340B priced drugs were used.
 10. The method ofclaim 8 wherein said previously adjudicated pharmacy claims are 340Bclaims.